Skip to content

Conversation

@tac0turtle
Copy link
Contributor

Overview

This pr restructures the docs and writes new sections in order to be better suited for users

@github-actions
Copy link
Contributor

github-actions bot commented Jan 28, 2026

The latest Buf updates on your PR. Results from workflow CI / buf-check (pull_request).

BuildFormatLintBreakingUpdated (UTC)
✅ passed⏩ skipped✅ passed✅ passedFeb 3, 2026, 11:30 AM

@claude
Copy link
Contributor

claude bot commented Jan 28, 2026

Claude finished @tac0turtle's task in 2m 17s —— View job


Documentation Review Complete

I've completed a comprehensive review of this documentation rewrite PR. This is an excellent effort to restructure and expand the documentation, adding substantial content across concepts, guides, and technical specifications. However, there are several issues that need attention before merging.


Critical Issues

1. Complete File Duplication

Location: docs/concepts/block-lifecycle.md and docs/reference/specs/block-manager.md

These two files are 100% identical (759 lines each). This creates a maintenance burden where updates to one file won't be reflected in the other.

Recommendation:

  • Keep one as the authoritative source
  • Have the other reference or link to it, OR
  • Differentiate their purposes (conceptual overview vs. technical specification)
  • Consider using VitePress includes if you want the same content in multiple places

Fix this →

2. Incorrect Code Implementation

Location: docs/ev-abci/migration-from-cometbft.md:190

The start command implementation is inconsistent with other guides:

// Current (INCORRECT):
RunE: func(cmd *cobra.Command, _ []string) error {
    return server.Start(cmd, evabci_server.StartHandler())
},

Should be (consistent with integration-guide.md:107 and integrate-ev-abci.md:88):

RunE: func(cmd *cobra.Command, _ []string) error {
    return evabci_server.StartHandler(cmd, app.New)
},

The current pattern wrapping StartHandler() with server.Start() is incorrect and will likely cause runtime errors.

Fix this →


High Priority Issues

3. Technical Inconsistency: Backoff Cap

Location: docs/concepts/block-lifecycle.md (also in block-manager.md due to duplication)

  • Line 296 states: "capped at DABlockTime"
  • Line 340 states: "capped at BlockTime"

These describe the same retry strategy but give different cap values. This needs to be consistent throughout the document.

Fix this →

4. Broken Internal Link

Location: docs/reference/specs/overview.md:14

Links to ./full_node.md but the actual file is ./full-node.md (with hyphen, not underscore).

- [Full Node](./full_node.md): Outlines...  # BROKEN

Should be:

- [Full Node](./full-node.md): Outlines...  # CORRECT

Fix this →


Medium Priority Issues

5. Typo: Double Space

Location: docs/concepts/p2p-networking.md:3

Every  node (both full and light) runs...

Extra space between "Every" and "node".

6. Formatting: Stray Character

Location: docs/reference/specs/full-node.md:31

The [Store] is initialized with `DefaultStore`, an implementation of the [store interface] which is used for storing and retrieving blocks, commits, and state. |

Trailing | character should be removed.

7. Formatting: Trailing Spaces

Location: docs/reference/specs/header-sync.md:25

The heading "### Data Sync Service" has trailing spaces.

8. Capitalization Inconsistency

Location: docs/guides/running-nodes/full-node.md:7

> **Note: The guide on how to run an evolve EVM full node...

Should be "Evolve" (capitalized) for consistency with the rest of the documentation.


Low Priority / Style Issues

9. Outdated Description (Minor)

Location: docs/guides/da-layers/celestia.md:51-59

The text description mentions --evnode.da.namespace as required, but then the actual command example correctly uses the newer --evnode.da.header_namespace and --evnode.da.data_namespace flags. The descriptive text should be updated to match.


Code Quality Notes

scripts/utils.mk Changes

The changes to scripts/utils.mk appear to be minor formatting adjustments based on the file content I reviewed. The Makefile targets for linting, dependencies, and mock generation look appropriate. No issues identified here.


Positive Observations

This PR demonstrates excellent work in several areas:

  1. Comprehensive Coverage: The new documentation covers concepts, integration paths, operations, and technical specs thoroughly
  2. Clear Structure: The reorganization into concepts/, getting-started/, guides/, and reference/ follows documentation best practices
  3. Mermaid Diagrams: Excellent use of sequence and flowchart diagrams to illustrate complex processes
  4. Multiple Execution Paths: Good coverage of Cosmos SDK, EVM, and custom executor paths
  5. Practical Examples: Code examples and command-line snippets throughout
  6. Cross-referencing: Good use of internal links (though a few need fixing)

Recommendations

  1. High Priority: Fix the critical issues (ABCI interface #1-4) before merging
  2. Testing: Verify all command examples actually work as documented
  3. Link Validation: Consider running a link checker tool on the documentation
  4. Consistency Pass: Do a final pass for terminology consistency (e.g., "Evolve" vs "evolve", "aggregator" vs "sequencer")
  5. Placeholder Content: The PR adds substantial real content, which is good. Gemini's review mentioned placeholder files, but I didn't find significant TODO-only files in my review.

Summary

This is a significant and valuable documentation improvement. The issues identified are fixable and don't diminish the overall quality of the work. Once the critical issues are addressed, this will be a major enhancement to the project's documentation.

Branch: marko/docs_rewrite

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @tac0turtle, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the project's documentation, providing a more organized and in-depth resource for developers and operators. It covers fundamental concepts, practical implementation steps for different execution environments, operational best practices, and detailed technical specifications, making it easier for users to understand, integrate, and manage Evolve-based chains.

Highlights

  • Comprehensive Documentation Restructuring: The documentation has been completely rewritten and reorganized into new conceptual guides, detailed integration and migration guides for both Cosmos SDK and EVM environments, operational guides, and comprehensive technical specifications. This aims to provide a more structured and user-friendly resource.
  • New Conceptual Guides: Introduced new conceptual documents covering core aspects like block lifecycle, data availability, fee systems, finality, P2P networking, sequencing modes (including forced inclusion and based sequencing), and transaction flow, enhancing understanding of Evolve's architecture.
  • Detailed Integration and Migration Paths: Added extensive guides for integrating ev-abci into Cosmos SDK applications, migrating existing CometBFT chains to Evolve, and setting up ev-reth for EVM rollups, including contract deployment and configuration. This provides clear pathways for developers to adopt Evolve.
  • Operational Guides and Tools: New guides for node operations such as deployment strategies, monitoring with Prometheus metrics, and using tools like the Blob Decoder and DA Visualizer have been added. Placeholders for troubleshooting and upgrade guides are also included, indicating future expansion.
  • Technical Specifications: Introduced a new section for technical specifications, detailing internal components like the block manager, block and header validity rules, the DA interface, full node architecture, header and data synchronization, and the storage system. This offers deep insights into Evolve's inner workings.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@codecov
Copy link

codecov bot commented Jan 28, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 55.96%. Comparing base (709d4db) to head (b458a5a).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3026      +/-   ##
==========================================
- Coverage   56.05%   55.96%   -0.10%     
==========================================
  Files         117      117              
  Lines       11844    11844              
==========================================
- Hits         6639     6628      -11     
- Misses       4475     4486      +11     
  Partials      730      730              
Flag Coverage Δ
combined 55.96% <ø> (-0.10%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a significant rewrite and restructuring of the documentation, adding a large volume of new content across concepts, guides, and reference sections. The effort to improve the documentation is commendable. However, there are several areas that need attention before this can be merged.

Firstly, there's a notable amount of content duplication, particularly between docs/concepts/block-lifecycle.md and docs/reference/specs/block-manager.md. This could lead to maintenance issues and should be resolved, perhaps by using includes or linking between documents.

Secondly, a large number of placeholder files have been added, containing only TODO comments. These should be either completed or removed.

Finally, there are various inconsistencies in technical details, formatting issues (like the use of :::: instead of ::: for VitePress admonitions), minor typos, and some broken links. Addressing these points will greatly improve the quality and usability of the new documentation.

Comment on lines +189 to +191
RunE: func(cmd *cobra.Command, _ []string) error {
return server.Start(cmd, evabci_server.StartHandler())
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

The implementation of the start command's RunE function appears to be incorrect and is inconsistent with other guides like integration-guide.md and getting-started/cosmos/integrate-ev-abci.md. The use of server.Start wrapping the evabci_server.StartHandler is not the standard pattern and will likely cause an error, preventing the node from starting. Please make this consistent with the other guides.

Suggested change
RunE: func(cmd *cobra.Command, _ []string) error {
return server.Start(cmd, evabci_server.StartHandler())
},
RunE: func(cmd *cobra.Command, _ []string) error {
return evabci_server.StartHandler(cmd, app.New)
},

Comment on lines +338 to +342
- **Centralized State Management**: The `retryStrategy` struct manages attempt counts, backoff timing, and gas price adjustments
- **Multiple Backoff Types**:
- Exponential backoff for general failures (doubles each attempt, capped at `BlockTime`)
- Mempool-specific backoff (waits `MempoolTTL * BlockTime` for stuck transactions)
- Success-based backoff reset with gas price reduction
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

There's an inconsistency in the documentation regarding backoff caps. Line 296 states that exponential backoff is "capped at DABlockTime", while the "Retry Strategy Features" section on line 340 says it's "capped at BlockTime". Please ensure this is consistent across the document.

@@ -0,0 +1,60 @@
# P2P

Every node (both full and light) runs a P2P client using [go-libp2p][go-libp2p] P2P networking stack for gossiping transactions in the chain's P2P network. The same P2P client is also used by the header and block sync services for gossiping headers and blocks.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

There is a typo with a double space after "Every".

Suggested change
Every node (both full and light) runs a P2P client using [go-libp2p][go-libp2p] P2P networking stack for gossiping transactions in the chain's P2P network. The same P2P client is also used by the header and block sync services for gossiping headers and blocks.
Every node (both full and light) runs a P2P client using [go-libp2p][go-libp2p] P2P networking stack for gossiping transactions in the chain's P2P network. The same P2P client is also used by the header and block sync services for gossiping headers and blocks.

Comment on lines 1 to 11
# Custom Precompiles

<!-- TODO: Create custom precompiles guide (ev-reth specific)
- What are precompiles
- ev-reth custom precompiles:
- Mint precompile
- Others as they exist
- Adding custom precompiles to ev-reth
- Chainspec activation configuration
- Reference: ev-reth repository
-->
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

This file is a placeholder with a TODO comment. Placeholder content should be completed or the file should be removed before merging a documentation rewrite PR. This comment applies to several other new files in this PR as well, such as docs/guides/operations/troubleshooting.md, docs/guides/operations/upgrades.md, docs/guides/running-nodes/aggregator.md, docs/guides/running-nodes/attester.md, docs/guides/running-nodes/light-node.md, and several files under docs/reference/.

Comment on lines 53 to 57
Now that we are posting to the Celestia DA instead of the local DA, the `evolve start` command requires three DA configuration flags:

- `--evnode.da.start_height`
- `--evnode.da.auth_token`
- `--evnode.da.namespace`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The description of required DA flags is outdated. It lists --evnode.da.namespace as a required flag, but this flag is deprecated. The text should be updated to reflect the use of --evnode.da.header_namespace and --evnode.da.data_namespace, as correctly shown in the command example later in the document.

Suggested change
Now that we are posting to the Celestia DA instead of the local DA, the `evolve start` command requires three DA configuration flags:
- `--evnode.da.start_height`
- `--evnode.da.auth_token`
- `--evnode.da.namespace`
Now that we are posting to the Celestia DA instead of the local DA, the `evolve start` command requires several DA configuration flags:
- `--evnode.da.start_height`
- `--evnode.da.auth_token`
- `--evnode.da.header_namespace`
- `--evnode.da.data_namespace`


This guide covers how to set up a full node to run alongside a sequencer node in a Evolve-based blockchain network. A full node maintains a complete copy of the blockchain and helps validate transactions, improving the network's decentralization and security.

> **Note: The guide on how to run an evolve EVM full node can be found [in the evm section](./evm/single.md#setting-up-a-full-node).**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

There's a typo in the note. It should be Evolve instead of evolve for consistency.

Suggested change
> **Note: The guide on how to run an evolve EVM full node can be found [in the evm section](./evm/single.md#setting-up-a-full-node).**
> **Note: The guide on how to run an Evolve EVM full node can be found [in the evm section](./evm/single.md#setting-up-a-full-node).**


### Store

The [Store] is initialized with `DefaultStore`, an implementation of the [store interface] which is used for storing and retrieving blocks, commits, and state. |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

There is a stray | character at the end of this line which should be removed.

Suggested change
The [Store] is initialized with `DefaultStore`, an implementation of the [store interface] which is used for storing and retrieving blocks, commits, and state. |
The [Store] is initialized with `DefaultStore`, an implementation of the [store interface] which is used for storing and retrieving blocks, commits, and state.

- Used by all node types (sequencer, full, and light)
- Essential for maintaining the canonical view of the chain

### Data Sync Service
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

There are trailing spaces at the end of this markdown heading which should be removed.

Suggested change
### Data Sync Service
### Data Sync Service

- [Block Components](./block-manager.md): Explains the modular component architecture for block processing in Evolve.
- [Block Validity](./block-validity.md): Details the rules and checks for block validity within the protocol.
- [Data Availability (DA)](./da.md): Describes how Evolve ensures data availability and integrates with DA layers.
- [Full Node](./full_node.md): Outlines the architecture and operation of a full node in Evolve.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The link to the full node specification appears to be broken due to a filename mismatch. The target file is full-node.md, not full_node.md.

Suggested change
- [Full Node](./full_node.md): Outlines the architecture and operation of a full node in Evolve.
- [Full Node](./full-node.md): Outlines the architecture and operation of a full node in Evolve.

- Updated Celestia guide to clarify prerequisites, installation, and configuration for connecting Evolve chains to Celestia.
- Enhanced Local DA documentation with installation instructions, configuration options, and use cases for development and testing.
- Expanded troubleshooting guide with detailed diagnostic commands, common issues, and solutions for node operations.
- Created comprehensive upgrades guide covering minor and major upgrades, version compatibility, and rollback procedures.
- Added aggregator node documentation detailing configuration, block production settings, and monitoring options.
- Introduced attester node overview with configuration and use cases for low-latency applications.
- Removed outdated light node documentation.
- Improved formatting and clarity in ev-reth chainspec reference for better readability.
@tac0turtle tac0turtle marked this pull request as ready for review January 28, 2026 12:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants